Magnum One/Magnum One (Mid-American Digital) (Disc Manufacturing).iso/d20/tick207.arc/PREREL.DOC

Text File | 1991-02-08 | 7KB | 175 lines

                            Pre-Release and Secondary Areas


           Tick 2.0 adds several enhancements,  two of the most  significant
      of  which  are  PRE-RELEASE and SECONDARY AREAS.   These are more dif-
      ficult to describe than to use.  What follows is an attempt to explain
      them.

           A little historic background may be helpful.   Back when the  SDS
      as we now know it got started, one of the ideas was that we could make
      provision  for  software to be distributed within the SDS-RC structure
      into each region before the official release  date,  so  that  when  a
      major release,  such as a new Binkley came around, it would be readily
      available everywhere at once on release day.   This  concept  is  PRE-
      RELEASE.    To date,  the only implementation had been in FLEA.   That
      provided the ability to distribute a file throughout the network,  but
      would  delay the toss to the downloadable directory until the official
      release time.   That was good so far as it went,  but it made the  as-
      sumption  that the SDS would consist of a small number of distribution
      nodes,  and that the net-level sysops would get the files  by  FREQing
      from  their  regional SDS nodes.   The SDS and other distribution net-
      works developed in a different direction, however.   In most cases the
      net level nodes are directly linked into the networks, elimination the
      need  for  FREQ  entirely.    This expansion rendered the simpler pre-
      release method unworkable.

           What was really needed was a method of limiting the  distribution
      of  pre-released  files to the core structure of the distribution net-
      work,  and to pass the files "down the  pipe"  on  the  release  date.
      hopefully, TICK should now make this possible.

           When  a file is hatched into an echo,  it will now be possible to
      specify a release delay of a certain number of days.   The  file  will
      immediately be sent only to those nodes which are designated as having
      permission  to receive pre-released files.   Those nodes will likewise
      send the file only to similarly privileged nodes.   Until the time  of
      release,  the  files  will  reside in a special "quarantine" directory
      (QDIR).  When the release time arrives, the file will be tossed to its
      destination directory,  and sent to those nodes  which  have  not  yet
      received it.  This is the basic PRE-RELEASE concept.

           SECONDARY AREAS is another added feature, which may be used inde-
      pendently or in conjunction with pre-release.   Presently,  file echos
      are defined with an echo tag, just as in echomail.  It is now possible
      to associate a secondary echo (carrying  its  own  echo  tag)  with  a
      primary echo.   In such a setup,  any files hatched or received in the
      secondary area would echo  only  in  that  area.    Files  hatched  or
      received  in the primary area would echo in both primary and secondary
      areas.   For example:  Someone recently mentioned in SOFTWARE that  he
      was receiving the new releases of "Remote Access" BBS directly from Oz
      in an echo with the tag of RA_DIST (That's not the actual name, but it

                                                                           1



      will  serve  for  now).    He  now  has  to  manually alter the tag to
      SOFTDIST to distribute it via SDS.   If RA_DIST is set up as a primary
      area,  with SOFTDIST as its secondary area,  he could receive the file
      in RA_DIST,  and distribute it in SOFTDIST automatically.   Note  that
      the  use of SOFTDIST as a secondary area of RA_DIST does not interfere
      with its usual use, where it is defined as a primary area elsewhere in
      the TIC.CFG file.   Also note that echoing in SOFTDIST  do  not  "flow
      backwards"  into  RA_DIAT.    A segment of a TIC.CFG with such a setup
      follows:


      Area c:\sds\softdist SOFTDIST
           1:266/12 Password *C
           2:512/26 Pass2    H
           1:116/26 Lhz       H

      Area c:\sds\racess RACESS SOFTDIST
           3:333/29 Pass3  *C
           1:261/662 Pop   *C
           1:116/29 kjn    C


           In the above segment,  files passed in SOFTDIST will echo as they
      always  have.    They  will  NOT be echoed to 1:266/12 or to 2:512/26.
      Files received in RACESS from 3:333/29 will be echoed to 1:261/662 and
      1:116/29 as RACESS,  and will be echoed to 1:266/12  and  2:512/26  as
      SOFTDIST  files.   (1:116/29 will NOT receive files received in RACESS
      as SOFTDIST file,  because when the primary  area  is  processed,  his
      seenby  is added before the secondary area [SOFTDIST] is processed ...
      He WILL receive files that were  received  in  SOFTDIST  as  SOTFTDIST
      files, however.)

                  Using Pre-Release and Secondary areas together


           Although  pre-release  is independent of secondary areas,  a good
      use of the combination would provide additional security  against  the
      premature  distribution  of  a  pre-released file.   What I thought of
      doing was this:  Set up a primary area for each  echo,  and  have  use
      those areas for pre-release files only.   Each primary area would have
      as a secondary area, the file echoes we all know and love.  Files that
      were not pre-release would be distributed in the usual echoes.    Pre-
      release files would travel in the pre-release echoes,  and be released
      into the normal echoes at release time.   For example:    SOFTDIST  is
      defined  as  a  primary  echo in one part of the TIC.CFG.   PRESOFT is
      defined as a primary echo in another part  of  the  TIC.CFG,  and  has
      SOFTDIST  defined  as  a secondary area to it.   Only authorized nodes
      would be linked to  PRESOFT,  while  the  whole  world  is  linked  to
      SOFTDIST.    A  pre-release  file  would  be distributed by the SDS-RC
      structure via PRESOFT,  and on  release  date  would  be  tossed  into
      SOFTDIST in each region simultaneously.   By using the separate areas,
      the chance of an unauthorized node inadvertently  being  sent  a  pre-
      release file is reduced.

                                                                           2

























































                                                                           3